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Tutorial  Agenda 


■  Complexity  of  Systems 

-  Failures  and  their  cause 

■  Implementation  and  Verification 

-  Developing  robust  systems 

■  Model  and  Code  Verification 

-  Addressing  design  and  code  errors 

■  Practical  Considerations 

-  Implementing  and  verifying  complex  systems 

■  Additional  Techniques  for  Improving  Software  Quality 

-  Addressing  standards  and  other  considerations 


Complexity  of  Systems 


Failures  and  their  cause 
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Complexity  of  Systems 

■  Modern  automotive  powertrain 

-  500  to  1 ,000  thousands  lines  of  code  (KLOC) 


■  Boeing  787  flight  control  system 

-  6,500  KLOC 

■  Software  in  spacecraft* 

-  3  to  1 ,700  KLOC 

1700 


Voyager  Galileo  Cassini  MPF  Shuttle  ISS 

(1977)  (1989)  (1997)  (1997)  (2000)  (2000) 


*Automated  Software  Verification  &  Validation:  An  emerging  approach  for  ground  operations 
Bell  and  Brat,  NASA 


Complex  Systems  Fail 


■  Ariane-5,  expendable  launch  system 

-  Overflow  error 

-  Resulted  in  destruction  of  the  launch  vehicle 


■  USS  Yorktown,  Ticonderoga  class  ship 

-  Divide  by  zero  error 

-  Caused  ship’s  propulsion  system  to  fail 


■  Therac-25,  radiation  therapy  machine 

-  Race  condition  and  overflow  error 

-  Casualties  due  to  overdosing  of  patients 
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Cost  of  Failure  -  Aerospace  Examples* 


System 

Cost 

Reason 

Ariane  5  (1996) 

$594M 

Overflow  software  error 

Delta  III  (1998) 

$336M 

SW  did  not  account  for 
normal  roll  oscillation 

Titan  IV  B  (1999) 

$1.5B 

Wrong  decimal  point  in  SW 
(const  -0.19..  vs.  -1.99..) 

Mars  Climate  Orbiter  (1999) 

$524M 

Wrong  units 

Zenit  3SL  (2000) 

$367M 

Premature  2nd  stage 
shutdown 

Messenger  (2004) 

$24  M 

SW  test  related  delays 
resulting  in  data  loss 

*Automated  Software  Verification  &  Validation:  An  emerging  approach  for  ground  operations 
Bell  and  Brat,  NASA 
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Why  Do  Complex  Systems  Fail?* 


■  Insufficient  specification 

■  Design  errors 

■  Software  coding  errors 

■  Mechanical  failure 

■  Deliberate  interference 

■  Human  errors 


*lssues  in  Safety  Assurance 
Martyn  Thomas,  SafeComp  2003 


Scope  of  Tutorial 


-  Insufficient  specification 

- ! - 

■  Design  errors 

■  Software  coding  errors^ 

■  Mechanical  failure 


Deliberate  interference 


Human  errors 


Embedded  Software 
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Design  Errors 


■  Poorly  designed  software 

-  That  may  or  may  not  adhere  to  specifications 

■  Avoiding  design  errors 

-  Not  easy,  issues  may  not  be  detected 

-  With  non-exhaustive  testing  or  simulation  methods 

■  Effects  include 

-  Software  crashes 

-  Unexpected  software  behavior 
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Design  Error  Examples 


Dead  logic 

Unreachable  states 

Deadlock  conditions 

Non-deterministic 

behavior 

Exception  conditions 


Overflow 
■  Divide  by  zero 
And  lots  more  . . . 


Software  Code  Errors 


■  Coding  defects 

-  Resulting  in  run-time  errors 

■  What  are  run-time  errors 

-  Also  known  as  “latent  faults” 

-  Rarely  manifest  and  are  infrequent 

■  Effects  include 

-  Software  crashes 

-  Unexpected  software  behavior 
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Run-Time  Error  Examples 


Non-initialized  data 

■  Out  of  bound  array  access 
Null  pointer  dereference 
Incorrect  computation 

■  Concurrent  access  to 
shared  data 


Illegal  type  conversion 

■  Dead  code 

■  Overflows 
Non-terminating  loops 
And  lots  more  . . . 


The  Vision  of  Zero  Defect  Software 


■  Is  it  possible? 

■  Yes,  but  with  some  caveats 

■  Is  it  applicable  to  all  types  of  software? 

■  No,  and  that’s  OK 

■  So  when  does  it  make  sense  to  invest  time, 
energy,  and  effort  to  create  zero  defect  s/w  . 


Constraining  the  Problem 


■  When  does  software  quality  truly  matter 

-  Human  lives  at  risk 

-  Missions  that  cannot  fail 

-  Business  operations  that  cannot  suffer  downtime 

■  Computer  devices 

-  High  integrity  embedded  systems 

-  Examples:  flight  control,  braking  systems, 
remote  cellular  base  stations,  ... 
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Introduction  to  High  Integrity 
Embedded  Systems 

■  General  embedded  systems 

-  Software  world-wide  increasing  10%  to  20%  per  year 

-  Embedded  microprocessors  account  >98% 

■  High  integrity  systems  found  in 

-  Aircraft,  automobiles,  medical  devices 

-  Safety  and  reliability  are  paramount 


■  Software  algorithms  contain 

-  Complex  controls  algorithms 

-  Computations  in  fixed  point  and  floating  point 

-  Logic,  state  based  machine  algorithms 

-  Multi-threaded  code  execution 
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Challenges  in  High  Integrity* 


■  Strong  correlation  between  application  size  and 
the  total  number  of  defects 

-  Estimated  30  defects  per  1000  lines  of  code 

-  20%  will  be  severe 

-  Defects  must  be  found  and  removed 

•  Time  and  resources  allocated  to  finding  and 
fixing  software  defects 

-  Most  expensive  aspect  of  software  development 


*  Embedded  software:  facts,  figures,  and  future 
Ebert  And  Jones,  IEEE  Computer  2009 
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Implementation  and  Verification  of 
Complex  Systems 


Implementing  and  Verifying  Complex  Embedded  Software  Systems 
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Software  for  an  Engine  Controller 


CD  7jLsufe 


CDt 


c z>S 


CD^i 


Aircraft  Engine 


Embedded  Controller 


rKD 


Complex  Algorithm 


KD 


angle  cmd 

angle 
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Design  Implementation  and  Verification 


System  Requirements 


Vehicle  Integration 
and  Calibration 


Software  Requirements 


Hardware/Software 

Integration 


Software 

Integration 


Coding 


Software  Design 
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Design  Implementation 


System  Requirements 


Software  Requirements 


Software  Design 


Coding 


RESEARCH 


REQUIREMENTS 
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Design  Implementation  with  Model 
Based  Design  (MBD) 
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Design  &  Code  Error  Manifestation 


System  Requirements 


Vehicle  Integration 
and  Calibration 


Software  Requirements 


Hardware/Software 

Integration 


Errors 

can  manifest  here 


Design  &  Code  Error  Detection 


Model  and  Code  Verification 


Addressing  design  and  code  errors 
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Solving  the  Problem  with  Model  and 
Code  Verification 

Model  Verification  Code  Verification 

►  Detect  and  fix  design  errors 

►  Robust  Design 

►  Detect  and  fix  code  errors 

►  Robust  Code 
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Design  Error  Detection  in  MBD 
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Process  of  Design  Error  Detection  in  MBD 


■  Verify  design  at  the  model  level  ( model  verification) 

-  Identify  issues  such  as  dead  logic 


■  Exhaustively  verify  design 


-  Using  formal  methods 


f - 

Simulink  Design  Verifier  Results 

□  ||  E  ||_£3 

=» 

’«,r  80 

Back  to  summary  -  Close  results 

input  port  1 T  SATISFIED'  -  View  test  case 
input  port  1  F  SATISFIED  -  View  test  case 
input  port  2  T  SATIS  FIE  D  -  View  test;  case 
input  port  2  F  SATISFIED  -  View  test  case 
input  port  3  T  U  IN  SATIS  FIABLE 
input  port  3  F  SATISFIED  -  View  test  case 
input  port  4  T  UNSATTS  FIABLE 
input  port  4  F  UNSATTSFIABLE 
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Formal  Methods 


■  Mathematical  based  techniques  for 

-  Specification,  development  and  verification  of  software 

■  Proof  based  verification 

-  Formally  prove  attributes  of  a  system 

-  Results  are  considered  “sound” 

■  Example  techniques 

-  Model  checking  for  exhaustive  search  for  all  states 

-  Abstract  interpretation  for  semantic  analysis  of  programs 
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Introduction  to  Abstract  Interpretation 


■  Formal  methods  based  verification 

-  Solution  that  can  be  applied  to  software  programs 

-  What  is  Abstract  Interpretation? 

-  Consider  the  multiplication  of  three  large  integers 


-4586  x  34985  x  2389  =  ? 
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Application  of  Abstract  Interpretation 


■  Abstract  result  of  computation  to  sign  domain 

-  Could  be  positive  or  negative 

-  Sign  of  the  computation  will  be  negative 

■  Determining  sign 

-  An  application  of  Abstract  Interpretation 

■  Technique  enables  precise  knowledge  of  some  properties 

-  The  sign,  without  having  to  multiply  integers  fully 

-  Sign  will  never  be  positive  for  this  computation 

■  Abstract  Interpretation  is  sound  and  exhaustive \y_  /proves 

-  That  sign  of  the  operation  will  always  be  negative 

-  And  never  positive 
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Verification  Tools  that  Implement  Model 
Checking  and  Abstract  Interpretation 


Verification  Tools 

Reference 

ImProve  for  building  high  assurance 
embedded  applications 

Tom  Hawkins 

UPPAALfor  modeling,  validation  and 
verification  of  real-time  systems 

Aalborg  University 

Stacktool  for  stack  overflow  checking  of 
embedded  software 

University  of  Utah 

DAEDALUS  for  validating  critical  software 

European  1ST  Programme 

And  many  others  . . . 

Search  engines,  Wikipedia,  .... 
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In  this  tutorial  ... 


■  We  use  MathWorks  verification  tools  to 
demonstrate  examples  of  applying  formal 
methods 

■  To  demonstrate  how  one  can  attempt  to 
achieve  zero  defect  software 

■  Applicable  to  any  tool  or  product  that 
implements  formal  methods 
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Confirming  sound  design 


Tutorial  Demo 


■  Design  verification  of  a  model 
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Verification  of  Handwritten  Code 
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Typical  Methods  of  Software 
Verification  and  Testing 


■  Code  reviews 

-  Fagan  inspections  to  reduce  coding  errors 

-  Process  needs  to  be  complemented  with  other  methods 

■  Dynamic  test 

-  Validate  that  software  meets  requirements 

-  Verify  the  execution  flow  of  software,  often  on  the  target 
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When  Are  You  Done? 


■  Dijkstra 

-  “Program  testing  can  be  used  to  show  the  presence 
of  bugs,  but  never  to  show  their  absence” 

■  Hailpern 

-  “Given  that  we  cannot  really  show  there  are  no  more 
errors  in  the  program,  when  do  we  stop  testing?” 
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^un-Time  Error  in  new _position() 


int  new_j?osition (int  sensorjjosl,  int  sensor_pos2) 

{ 

Int  actuator  position; 

Int  x,  y ,  tmp_pos ,  magnitude; 


actuator  position  =2;  /*  default  */ 
tmp  ms  =  0;  /*  values  */ 

magnitude  =  sensor_posl  /  100; 
y  =  magnitude  +  5 ; 
x  =  actuator  position; 


while  (actuator^oosition  <  10) 

{ 

actuator  nosition++ ; 
tmpjpos  +=  sensor_pos2  /  100; 
y  +=  3; 

} 

if  { (3 *magnitude  +  100)  >  43) 

{ 

nagni tude++ ; 

x  =  actuator  position; 

actuator  ^position  =  x  /  (x  -  y)  ; 

} 

return  actuator  position  +  tmp  nos ;  /*  new  value  */ 

} 
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Find  the  Run-Time  Error  in  new _position() 

int  new_j?osition  tint  sensorjjosl,  Lnt  sensor_pos2) 


Consider  the  operation:  x  /  (x  -  y) 


Potential  run-time  errors 

-  Variables  x  and  y  may  not  be  initialized 

-  An  overflow  on  subtraction 

-  If  x  ==  y,  then  a  divide  by  zero  will  occur 


How  to  prove  that  run-time  errors  do  or  do  not 

exist? 
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de  Review  of  new _position() 


lnt  new_joosition { lnt  senaorjposl,  int  sensor_pos2) 

{ 

lnt  actuatorjosition; 

lnt  xr  y r  tmp_pos,  magnitude; 


actuator  position  =2;  /*  default  */ 
tmp_pos  =0;  /*  values  */ 

magnitude  =  sensor  oosl  /  100; 
y  —  magnitude  +  5 ; 
x  =  actuator_posltion ; 

while  (actuator  •position  <  10) 

actuator _posltion++ ; 
tmpjpos  +=  sensor  pos2  /  100; 
y  +=  3; 

} 

if  ( (3*magnitude  +  100)  >  43) 

{ 

magnf tude++ ; 
x  =  actuator_position ; 
actuatorjiosition  =  x  /  (x  -  y)  ; 

} 

return  actuator  position  +  tmp  ~oos ;  /*  new  value  */ 

} 
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de  Review  of  new _position() 


int  n.ew_j30sition  {int  sensorjosl,  int  sensor_pos2) 

]{ 

lnt  actuatorjiosition; 
lnt  x,  y i  tmp_pos,  magnitude; 

actuator  position  =2;  /*  default  * 
tmp_pos  =0;  /* 

magnitude  =  sensor_ 
y  —  magnitude 
x  =  actuator_pos: 

while  (actuator^positioi 

]  { 

actuatoj 
tm| 

y  +=  3; 

} 

if  ( (3*magnltude  + 

1  { 

magn: 

x  =  actuatorjos/tioi 
actuatorjosit; 

} 

return  actuator  position  +  tmp  ~oos ;  /*  new  value  */ 

} 


Variables  may  not 
be  initialized 
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de  Review  of  new _position() 


Lnt  new_jDosition { lnt  senaorjposl,  int  sensor_pos2) 

{ 


lnt  actuatorjosition; 


Variables  may  not 
be  initialized 


Overflow 

potential 
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de  Review  of  new _position() 


Lnt  new_jDosition { lnt  senaorjposl,  int  sensor_pos2) 

{ 


lnt  actuatorjosition; 


Variables  may  not 
be  initialized 


Overflow 

potential 


Division  by 
zero  potential 
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Code  Review  and  Dynamic  Test 


■  Code  review  results 

-  Initially  identified  potential  divide  by  zero  condition 

-  Deeper  review  shows  potential  overflow  and 
initialization  issues 

■  Next  step  is  to  Test 

-  Validate  that  code  written  to  meet  requirements 

-  Verify  that  the  code  is  robust  and  will  not  fail 
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Requirements  Specification 


■  Compute  new  position  of  control  arm  based  on  2 
position  sensors 

■  Implement  algorithm  as  modeled  in  the  Simulink 
modeling  environment 


■  Return  value  of  new  position  shall  be  within  ±  228 
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imic  Test  with  a  Test-Harness 


y'  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  * 

*  test  harness  to  validate  function  newjositionf] 
***************************************************y 
main  {void)  { 
int  x  j.  i  r  j  ; 


y ******************************************************** ******* 

*  Requirement  spec  states  that:  -2A2B  <  result  <  2A2B 

*  Inputs  to  function:  can  be  full  range  (signed  32  bit  target) 
******************************* ********************************y 

y  ***********  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  ************************************ 

*  Exhaustive  testing  not  possible,  so  lets  check  for  -100  to  100 

*  and  a  few  other  spot  checks 

*********************** ****************************************y 

/*  Try  -100.. 100  X  -100.. 100  */ 
for  (i  =  -100;  i  <  101;  i++  ) 

{ 

for  (j  =  -100;  j  <  101;  j++  ) 

{ 

x  =  new _ p osition {i ,  j)  ; 

if  ( (x  >  -263435456)  &&  (x  <  263435456)) 

{ 

printf  {’’PASS:  i=%d,  j=%d,  x=%d\n” ,  i,  j,  x)  ; 
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Exhaustive  Testing  of  new _position() 


■  Both  inputs  are  signed  int32 

-  Full  range  inputs:  -  231-  1  .  .  +231- 1 

-  All  combinations  of  two  inputs:  4.61X1018  test-cases 

■  Test  time  on  a  Windows  host  machine 

-  2.2GHz  T7500  Intel  processor 

-  4  million  test-cases  took  9.284  seconds 

-  Exhaustive  testing  time:  339,413  years 


Exhaustive  Testing  is  Impossible 


How  to  Increase  Confidence? 


■  Could  do  more  spot  testing 

-  But  it  is  still  not  exhaustive 

■  Add  defensive  code  (if  x  !=  y  .. .) 

-  This  will  protect  against  divide  by  zero! 

-  But  adds  more  code  and  execution  overhead 

-  What  about  other  potential  errors  like  overflow? 

■  Wish  that  the  code  will  not  fail 

-  Is  that  a  good  strategy  . . . 


What  about  static  code  analysis  tools? 

-  Compiler  warnings  and  more  sophisticated  tools 


Introduction  to  Static  Code  Analysis 


■  Scanning  source  code  to  automate  software  verification 

■  Range  from  unsound  methods  to  sound  techniques 
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Introduction  to  Static  Code  Analysis 


■  Scanning  source  code  to  automate  software  verification 

■  Range  from  unsound  methods  to  sound  techniques 
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sophistication 


Introduction  to  Static  Code  Analysis 


low 


Scanning  source  code  to  automate  software  verification 
Range  from  unsound  methods  to  sound  techniques 

Compiler  warnings 
-  Incompatible  type  detection,  etc. 


Bug  finding 

-  Pattern  matching,  heuristics,  data/control  flow 


Formal  methods 

-  Sound  proof  based  techniques,  applied  to  source  code 


Compiler  Warning  Example 
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vo^d  Ar c_f  (float  *y}  rK 

void  Arg_f (float  *y} 

□  { 

*y=12 . 0 ; 

L> 

void  WrongArg (void) 

Bi 

volatile  int  r=Q; 

Arg_f  (&r»  r- 
r  =  1/  (1-x) ; 

L  > 
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Compiler  Warning  Example 


1 

2 

3 

4 

5 

6 
7 
3 
9 

10 

11 

12 

13 

14 


vo^d  Arc_f (float  *y}  rK 
void  Arg_f (float  *y} 

EK 

*y=L2 . 0 ; 

> 

void  WrongArg (void) 

□  { 


$  gcc  -c  -Wall  src.c 

src.c:  In  function  WrongArg1: 

src.c:12:  warning:  passing  arg 

S 


Arg_f'  from  incompatible  pointer  type 
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Compiler  Warnings  for  new _position() 


1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 


int  new  position {int  sensor  posl,  int 

Bl 

int  actuator_position; 

int  x,  y,  tmp  nos  r  magnitude; 

actuator ^position  =2;  /*  default  */ 
tmp^pos  =  0;  /*  values  */ 

magnitude  —  sensor_posl  /  100; 
y  =  magnitude  +  5 ; 
x  =  actuator  position; 

,  Ti_.  ^  n  ^  •  +.  a  ^  ^  -i  n\ 


s ensor_pos2 ) 
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Compiler  Warnings  for  new _position() 


1 

2 

3 

4 

5 

6 
7 
6 
9 

10 

11 


int  new  position {int  sensor  posl,  int 

Bl 

int  actuator_position; 

int  x,  y,  tmp  nos  r  magnitude; 

actuator ^position  =2;  /*  default  */ 
tmp^pos  =  0;  /*  values  */ 

magnitude  —  sensor_posl  /  100; 
y  =  magnitude  +  5 ; 
x  =  actuator  position; 


,  Tl_.  ^  4-  A  ^  -1  n 


s ensor_pos2) 


5  gcc  -c  -Wall  where_are_er rors . c 

5 
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Static  Analysis  with  Splint  (splint.org) 


http://splint.org/ 


c 


T  Google 


Splint  -  Secure  Programming  Lint  info@spiint  om 

Download  -  Documentation  -  Manual  -  Links  Reporting  Blips  -  Mailing  Lists  Sponsors  -  Credits 


Splint 

Annotation-Assisted  Lightweight  Static  Checking 

Inexpensive  Program  Analysis  Group 

University  of  Virginia  Department  of  Computer  Science 


Secure  Programming  Lint 
Specifications  Lint 
First  Aid  far  Programmers 


Splint  is  a  tool  for  statically  checking  C  programs  for  security  vulnerabilities  and  coding  mistakes.  With  minimal  effort,  Splint 
can  be  used  as  a  better  lint.  If  additional  effort  is  invested  adding  annotations  to  programs,  Splint  can  perform  stronger 
checking  than  can  be  done  by  any  standard  lint. 
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Static  Analysis  with  Splint  (splint.org) 


http://splint.org/ 


c 


T  Google 


Splint  -  Secure  Programming  Lint  info@spiint  om 

Download  -  Documentation  -  Manual  -  Links  Reporting  Blips  -  Mailing  Lists  Sponsors  -  Credits 


Splint 

Annotation-Assisted  Lightweight  Static  Checking 

Inexpensive  Program  Analysis  Group 

University  of  Virginia  Department  of  Computer  Science 


Secure  Programming  Lint 
Specifications  Lint 
First  Aid  far  Programmers 


Splint  is  a  tool  for  statically  checking  C  programs  for  security  vulnerabilities  and  coding  mistakes.  With  minimal  effort,  Splint 
can  be  used  as  a  better  lint.  If  additional  effort  is  invested  adding  annotations  to  programs,  Splint  can  perform  stronger 
checking  than  can  be  done  by  any  standard  lint. 


$  splint  -strict  where_are_er rors . c 
Splint  3.1.1 - 09  Aug  2007 

where_are_er rors . c: 1: 5 :  Function  new_position  declared  but  not  used 

A  function  is  declared  but  not  used.  Use  /*@unused@*/  in  front  of  function 
header  to  suppress  message.  (Use  -fcnuse  to  inhibit  warning) 
where_are_er rors . c: 25 : 1:  Definition  of  new_position 
where_are_er rors . c : 1: 5 :  Function  new_position  exported  but  not  declared  in 

header  file 

A  declaration  is  exported,  but  does  not  appear  in  a  header  file.  (Use 
-exportheader  to  inhibit  warning) 
where_are_er rors . c: 25 : 1:  Definition  of  new_position 

Finished  checking - 2  code  warnings 

s 


Verification  Results  on  new _position() 


Required  Checks 

Activity 

Comments 

Status 

Code  Review 

Identified  potential  non- 
initialized  variables,  overflows, 
and  divide  by  zero 

Further  examination 
required 

Dynamic  Test 

Test  to  requirements 

Pass 

Additional  Confidence  Checks 

Activity 

Comments 

Status 

Compiler  warnings 

None 

No  issues 

Static  Code  Analysis 

Splint  with  -strict 

No  issues 

Formal  methods 
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Formal  Methods  Based  Static  Code 
Analysis 

■  Detects  and  proves  the  absence  of  certain  run-time  errors 


■  Operates  at  source  code  level 
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Polyspace  Static  Code  Analysis  Results 
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Returning  to  our  Example  new _position() 

int  new_j?osition tint  sensorjjosi,  Lnt  sensor_pos2) 


Polys  pace  Results  on  new _position() 


Tutorial  Demo 


■  Verification  results  for  new_position() 

■  Results  for  new_position()  with  added  protection 
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How  to  Prove  x!  ^  for  x/  (  x-  y) 
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How  to  Prove  x!  ^  for  x/  (  x-  y) 


Type  Analysis  (bounding  conditions) 
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How  to  Prove  x!  ^  for  x/  (  x-  y) 


With  Abstract  Interpretation 


No  code  execution 
No  test-cases 

Exhaustive/ 

Proven/ 
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Advantages  and  Disadvantages 


■  Advantages 

-  Deep  formal  methods  based  code  verification 

-  Can  formally  prove  that  code  is  defect  free 

and  formally  prove  absolute  existence  of  a  defect 

-  Sound  technique  ...  identifies  all  potential  failure  points 

■  Disadvantages 

-  Compute  intensive,  will  take  time  to  run 

-  In  practice  limited  to  projects  with  <1  MLOC 

-  If  results  are  viewed  conservatively, 
all  potential  defects  must  be  reviewed 
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Verifying  Complex  Handwritten  Code 


Tutorial  Demo 


■  Identifying  run-time  errors  (reds) 

■  Dead  code  (grays) 

■  Understanding  potentially  failing  code  (oranges) 

■  Analysis  of  multithreaded  coded 


Range  Violation  Detection 


■  Some  applications  assume  certain  variable  range 

-  E.g.  angle  in  degrees  must  be  between  0  and  359 

-  May  simplify  simulation  and  test 

■  What  happens  if  range  is  violated? 

■  How  to  detect  range  violations  exhaustively? 
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Range  Violation  Detection 


■  Range  violation  detection 
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Practical  Considerations  of 
Implementing  and  Verifying 
Complex  Systems 


Context  of  automatic  code  generation  from  Model  Based  Design  (MBD)  and 
the  reality  of  mixed  model  and  code  environments 
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Verification  of  a  System 


RESEARCH 


REQUIREMENTS 


DESIGN 

Handwritten 

Code 


DESIGN 


Environment  Models 


Mechanical 


Electrical 


Supervisory  Logic 


Control  Algorithms 


IMPLEMENTATION 


Hand 

1  t  \  1 

Generated 

Third  Party 

Code 

C/C++ 

w  l - J  ’ 

Code 

MCU 

DSP 

INTEGRATION 
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Returning  to  our  Engine  Controller 


Embedded  Controller 


Code 


CH)  "'^sufe 


Gpi! 


Complex  Algorithm 

Model  +  Code 


*CD 


r+CD 


Aircraft  Engine 
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Automatic  Code  Generation  from  Model 
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Automatic  Code  Generation  from  Model 


Generated  code  consists  of 

-  Subsystems  and  model  references 

Often  includes  handwritten  code 

-  S-Functions  and  legacy  code 

-  Individually,  small  in  size  (100s  LOC) 

-  May  be  automatically  repeated  many 
times  within  generated  code 


Automatic  Code  Generation  from  Model 


Oft  i  no  ides  1'"  ndwt  t  co 

$4;  net  ?ns  ?  id  legacy  code 


■  Robustness  issues  to  consider 

-  Handwritten  code  fails,  or  causes 
generated  code  to  fail 

-  Generated  code  may  cause  handwritten 
code  to  fail  ( Interface  related  failures) 

-  Handwritten  code  is  not  visible  to 
modeling  tools 


Generated  code 
from  model 
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Integration  of  Generated  Code 


Embedded  Software 
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Integration  of  Generated  Code 
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Integration  of  Generated  Code 


Code  integration 

-  Generated  code  stitched  together  with 
handwritten  code 


-  All  components  integrated  with 
handwritten  code 


Embedded  Software 


Integration  of  Generated  Code 


5e  e  ated  code  site  ic;  togethe  w  h 
andwr  ten  core 

AH  components  itegrated  v\  ih 


■  Robustness  issues  to  consider 

Design  error  in  the  generated  code 

-  Runtime  error  in  handwritten  or 
3rd  party  code 

How  do  you  ensure  the  entire  system 
is  robust? 

-  How  to  verify  generated  code  at 
interface  level? 


Embedded  Software 
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Verification  of  Mixed  Model  and  Code 


Tutorial  Demo 


■  Checking  handwritten  code  in  the  models 

■  Verifying  the  generated  code 

■  Verifying  integrated  code 
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Additional  Techniques  for  Improving 
Software  Quality 


Getting  near  to  zero  defect  goal 


81 


Enforce  Code  Standards 


■  C  is  a  very  flexible  language 

-  char  **********ptr,-  is  valid  syntax 

-  You  can  also  write  code  without  comments 

■  Are  these  good  practices? 

-  In  general,  NO 

■  Important  to  follow  some  code  standards 

-  Examples:  MISRA  C/C++,  JSF++ 
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Using  Code  Standards 


■  Example  standards 

-  MISRA  (Motor  Industry  Software  Reliability  Association), 
developed  for  automotive,  but  used  outside  in  other  industries 

-  JSF++  (Joint  Strike  Fighter  Air  Vehicle  C++) 

■  Facilitate 

-  Code  safety,  portability  and  reliability 

■  Code  rules 

-  Some  required,  others  advisories 

-  Various  categories,  such  as  style,  environment,  and  run-time 
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Example  MISRA  Rules 


■  Required 

-  All  object  and  function  identifiers  shall  be  declared  before  use 

-  The  right  hand  side  of  a  "&&"  or  "||"  operator  shall  not  contain 
side  effect 

-  The  statement  forming  the  body  of  an  "if",  "else  if",  "else", 
"while",  "do  ...  while",  or  "for"  statement  shall  always  be 
enclosed  in  braces 

■  Advisory 

-  Should  not  directly  use  basic  types  such  as  char,  int,  float  etc. 

-  All  declarations  at  file  scope  should  be  static  where  possible 

-  Tests  of  a  value  against  zero  should  be  made  explicit,  unless 
the  operand  is  effectively  Boolean 


84 


Applying  Coding  Standards 


Tutorial  Demo 


■  Application  of  MISRA  C  coding  standards 

■  Measuring  the  improvement  in  quality 
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Enabling  Software  Quality 


■  Ideal  goal,  create  software  with  zero  defects 

■  In  reality,  must  have  a  quality  mandate 

-  Internally  or  required  externally 

-  To  meet  specific  software  quality  objectives 

■  Define  a  quality  model  with  objectives 

-  Enables  a  prescriptive  solution  to  achieve  quality 
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Runtime  Defects  in  Software 


Software  will  contain  runtime  defects 

-  Cannot  eliminate  all  defects  in  one  step 

Incremental  processes  are  needed 

-  Different  quality  objectives  and  levels 

Ex.  quality  model  with  objectives 

-  Six  levels,  s/w  quality  objectives  (SQO) 

-  For  intermediate  development  and 
verification  stages 
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Incremental  Steps  to  Achieve  Quality 
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Incremental  Steps  to  Achieve  Quality 


Eliminate  some  runtime  defects 


By  quantifying  code  verification  results 

-  Red,  Gray,  Orange 

-  MISRA  Rules 

-  Code  complexity  metrics 
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Incremental  Steps  to  Achieve  Quality 

Software  Quality  Objectives  #1 


SQOI 


Meet  specific  code  complexity  thresholds 
Compliant  to  defined  1st  MISRA-2004  rules  subset 


First  level  has  limited  scope 

-  Subsequent  levels  increase  scope 

-  Runtime  defects  may  still  remain  in 
code 
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Incremental  Steps  to  Achieve  Quality 


SQOI 


•  Meet  specific  code  complexity  thresholds 

•  Compliant  to  defined  1st  MISRA-2004  rules  subset 

SQ02 

•  No  systematic  run-time  errors  (i.e.  no  reds) 

•  No  unintentional  non-terminating  constructs 


■  Second  level  increases  scope 

-  More  runtime  defects  eliminated 

-  But,  runtime  defects  may  still  remain 


■  For  an  intermediate  delivery 

-  Subsequent  levels  will  improve  quality 
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Incremental  Steps  to  Achieve  Quality 


SQOI 


SQ03 

•  No  unreachable  branches  (i.e.  no  dead  code) 


•  Meet  specific  code  complexity  thresholds 

•  Compliant  to  defined  1st  MISRA-2004  rules  subset 

SQ02 

•  No  systematic  run-time  errors  (i.e.  no  reds) 

•  No  unintentional  non-terminating  constructs 
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Incremental  Steps  to  Achieve  Quality 


SQOI 


SQ03 

•  No  unreachable  branches  (i.e.  no  dead  code) 


SQ04 

•  Achieve  1st  subset  of  non-systematic  run-time  errors 
(i.e.  specified  percentage  of  orange) 


•  Meet  specific  code  complexity  thresholds 

•  Compliant  to  defined  1st  MISRA-2004  rules  subset 

SQ02 

•  No  systematic  run-time  errors  (i.e.  no  reds) 

•  No  unintentional  non-terminating  constructs 
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Incremental  Steps  to  Achieve  Quality 


SQOI 


SQ03 

•  No  unreachable  branches  (i.e.  no  dead  code) 


SQ04 

•  Achieve  1st  subset  of  non-systematic  run-time  errors 
(i.e.  specified  percentage  of  orange) 


SQ05 

•  Compliant  to  defined  2nd  MISRA-2004  rules  subset 

•  Achieve  2nd  subset  of  non-systematic  run-time  errors 


•  Meet  specific  code  complexity  thresholds 

•  Compliant  to  defined  1st  MISRA-2004  rules  subset 

SQ02 

•  No  systematic  run-time  errors  (i.e.  no  reds) 

•  No  unintentional  non-terminating  constructs 


94 


Incremental  Steps  to  Achieve  Quality 


SQOI 


SQ03 

•  No  unreachable  branches  (i.e.  no  dead  code) 


SQ04 

•  Achieve  1st  subset  of  non-systematic  run-time  errors 
(i.e.  specified  percentage  of  orange) 


SQ05 

•  Compliant  to  defined  2nd  MISRA-2004  rules  subset 

•  Achieve  2nd  subset  of  non-systematic  run-time  errors 


SQ06 

•  Achieve  3rd  subset  of  non-systematic  run-time  errors 


•  Meet  specific  code  complexity  thresholds 

•  Compliant  to  defined  1st  MISRA-2004  rules  subset 

SQ02 

•  No  systematic  run-time  errors  (i.e.  no  reds) 

•  No  unintentional  non-terminating  constructs 
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DO-178B  Certification  Credit  with 
Verification  Tools 


■  Partial  credit  for  the  following: 

-  Table  A-5 

■  Ref.  Section:  6.3.4b,  6.3.4c,  6.3.4d,  6.3.4f 

-  Table  A-6 

■  Ref.  Section:  6.4. 2.1, 6. 4. 2. 2,  6.4.3 

■  Next  slide  explain  6.3.4.b  and  6.3. 4.f 
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Certification  Credit  for  6.3.4.b 


■  Objective 

-  Compliance  with  the  software  architecture 

-  The  objective  is  to  ensure  that  the  Source  Code  matches  the 
data  flow  and  control  flow  defined  in  the  software  architecture 

■  How  tools  can  be  used 

-  The  data  flow 

■  Prove  adherence  to  this  aspect  of  the  standard,  as  it  automatically  builds  global 
data  dictionary  and  identification  of  shared  data  reading  and  writing  accesses 

■  Artifacts 

-  Data  dictionary,  concurrent  access  graph,  etc. 
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Certification  Credit  6.3.4.f 


■  Objective 

-  Determine  the  consistency  of  the  Source  Code,  including  stack 
usage,  fixed  point  arithmetic  overflow  and  resolution,  resource 
contention,  worst-case  execution  timing,  exception  handling, 
use  of  uninitialized  variables  or  constants,  unused  variables  or 
constants,  and  data  corruption  due  to  task  or  interrupt  conflicts 

■  Code  verification  helps  to  identify 

-  Exhaustively:  Fixed  point  arithmetic  overflows,  use  of 
uninitialized  variables  and  constants,  etc. 

-  Partially:  Unused  variables  and  constants 

■  Artifacts 

-  Color  coding  to  identify  quality  of  code 

-  Report  generation  for  artifact  purpose 
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Conclusion 


Summary  of  tutorial 
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Adopting  New  Processes 

Short  Term 


■  Detect  and  fix  design  and  code  errors 

-  Unreachable  states,  dead  logic,  etc. 

-  Fix  code  level  run-time  errors 

■  Simplify  code  review  process 

-  Take  verification  results  to  code  review 

■  Develop  better  test-cases 

-  Improve  coverage  analysis 

-  Understand  impact  of  variable  ranges 
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Adopting  New  Processes 

Long  Term 

■  Make  verification  a  part  of  your  quality 
improvement  process 

-  Monitor  quality  and  status 

■  Leverage  verification  for  certification 

-  Maybe  possible  to  skip  some  processes 

-  E.g.  show  code  does  not  contain  divide  by  zeros 
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Conclusion 


■  Complexity  of  systems 

-  Learn  from  past  failures 

■  Model  and  code  verification 

-  Address  design  and  code  with  error  detection  and  proof 

-  Use  model  verification  to  detect  and  fix  design  errors 

-  Use  code  verification  to  detect  and  fix  coding  errors 

■  Practical  considerations 

-  Improve  robustness  in  mixed  model  and  code  environments 

■  Additional  techniques  for  improving  software  quality 

-  Coding  standards  such  as  MISRA  and  JSF 

-  Certification  standards  such  as  DO-178B 

-  Achieving  quality  goals  with  software  quality  objectives 


102 


Acronyms 


DSP  -  Digital  Signal  Processor 

JSF  -  Joint  Strike  Fighter 

KLOC  -  Thousands  (K)  of  Lines  of  Code 

LOC  -  Lines  of  Code 

MBD  -  Model  Based  Design 

MCU  -  Micro  Control  Unit 

MISRA-  Motor  Industry  Software  Reliability  Association 
MLOC  -  Millions  of  Lines  of  Code 


SW  -  Software 

SQO  -  Software  Quality  Objectives 
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